fix(errors): describe the mutation coordination lock truthfully - #314

What changed

• Define the lock precisely as coordination between foreground PV self-update and queued daemon mutations.
• Keep the legacy ~/.pv/run/update.lock path and existing lock lifetime unchanged.
• Document that the persistent file is not evidence of contention and that stale unlocked files remain harmless.
• Document that previously persisted job text is historical and is not rewritten.
• Replace update-specific typed errors with CoordinationLockHeld across state, CLI, and daemon paths.
• Update CLI and JSON-visible daemon snapshots to use the same neutral wording.

Why

Both foreground self-update and daemon reconciliation/update work acquire the same OS lock. The previous error always claimed “PV update is already in progress,” even when reconciliation held it, and could be read as saying the persistent file itself caused contention.

The new wording identifies the exact coordination scope and the active OS lock while leaving mutual exclusion behavior untouched.

Review commits

1. docs(design): define mutation coordination lock scope
2. fix(errors): use neutral coordination lock wording

Checks

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
• cargo nextest run -p state (84 passed)
• cargo nextest run -p cli --test update --test project_open (46 passed)
• cargo test -p daemon --lib (108 passed)
• cargo test -p daemon --test daemon_foundation (30 passed)

Closes #308